Auto-Configuring Multi-Layer Network

ABSTRACT

An auto-configuring multi-layer network including different communication protocols, namely both wired and wireless protocols, interchangeably and indifferently to interconnect various devices such as, for example, controllers, actuators, alarms, sensors, interfaces, etc. The auto-configuring multi-layer network uses a virtualization functionality that mirrors devices from one layer having a given communication protocol unto another layer having a different communication protocol.

TECHNICAL FIELD

The present invention relates to an auto-configuring multi-layernetwork.

BACKGROUND

Bridges have commonly been used to allow two networks to communicatewith each other. These networks might be the same type of network, liketwo wired networks, or different networks, like a wired network andwireless network.

In order to achieve both wired broadcast and wireless mesh communicationin a network, an option is to have a redundant (or parallel) setup witha wired network and a wireless network both communicating with everynode.

In this setup, a “redundancy server” can communicate with any nodeeither through the wired or wireless network. If one of the two networksfails, for example the wired network, the redundancy server can stillcommunicate through the other network, i.e. the wireless network, butthe “failed” network will be down for all of the nodes.

However, no solution up to date solution enables the use of anautonomous wired sub-network within a wireless environment.

SUMMARY

To overcome the above-mentioned problems of the prior realizations, thepresent invention is concerned with an auto-configuring multi-layernetwork.

According to an illustrative example of the present invention, there isprovided a method for auto-configuring a multi-layer network includingat least two layers using different communication protocols tointerchangeably interconnect at least two nodes, the method comprising:

-   providing each node with an information packet including:

a unique identifier;

a function identifier;

a link quality; and

a time to live counter;

-   for each node, broadcasting at defined intervals a heartbeat packet    including:

an indicator that the packet is a heartbeat packet;

a layer node identifier specific identifying the broadcasting nodewithin a given layer; and

the information packet of the broadcasting node;

-   identifying nodes connected to at least a first layer and a second    layer of the at least two layers as virtualizer nodes;-   for each virtualizer node:    -   a) mirroring nodes observed by the virtualizer node on the first        layer onto the second layer, including assigning each first        layer node a layer node identifier on the second layer; and    -   b) mirrors nodes observed by the virtualizer node on the second        layer onto the first layer, including assigning each second        layer node a layer node identifier on the first layer;-   for each node, building a registry comprising an entry for each node    from which a heartbeat is received, the registry entry including:

the unique identifier of the node from which a heartbeat is received;and

the layer node identifiers of the node from which a heartbeat isreceived;

wherein a source node selects a layer to communicate with a destinationnode based on the source node registry.

According to an illustrative example of the present invention, there isprovided a method for auto-configuring a multi-layer network includingat least two layers using different communication protocols tointerchangeably interconnect at least two nodes, further comprising:

-   triggering the broadcasting of a locator packet of the source node    to establish a collaboration with at least one desired collaboration    node, the source node locator packet including:

an indicator that the packet is a locator packet; and

the information packet of the source node;

-   triggering the broadcasting of a locator packet of the at least one    desired collaboration node within a localization period associated    with the source node, each desired collaboration node locator packet    including:

an indicator that the packet is a locator packet; and

the information packet of the desired collaboration node;

-   initiating the collaboration between the source node and the at    least one desired collaboration node on the basis of their    respective functional identifiers; and-   broadcasting that the collaboration between the source node and the    at least one desired collaboration node was successfully initiated    until a collaboration broadcasting period expires.

The foregoing and other objects, advantages and features of the presentinvention will become more apparent upon reading of the followingnon-restrictive description of illustrative embodiments.

BRIEF DESCRIPTION OF THE DRAWINGS

Non-limitative illustrative embodiments of the invention will now bedescribed by way of example only with reference to the accompanyingdrawings, in which:

FIG. 1 is a schematic view of an example of an autonomous wiredsub-network within a wireless network;

FIG. 2 is a schematic view of a first example of a prior artsurveillance network;

FIG. 3 is a schematic view of a second example of a prior artsurveillance network;

FIG. 4 is a schematic view of an auto-configuring multi-layer networkaccording to an illustrative embodiment of the present invention;

FIGS. 5 a, 5 b and 5 c are schematic views showing communication betweennodes over an auto-configuring multi-layer network;

FIG. 6 is a schematic view of an auto-configuring multi-layer networkshowing the bridging concept;

FIG. 7 is a schematic view of the hierarchical structure of thecomponents of the auto-configuring multi-layer network;

FIG. 8 is a schematic view of an example of the functional states ofnodes in an auto-configuring multi-layer network at boot up;

FIG. 9 is a state diagram of the FNID selection state machine;

FIG. 10 is a state diagram for the virtualizer node assignation statemachine;

FIG. 11 is a state diagram the node registry update state machine;

FIG. 12 is a schematic view of an auto-configuring multi-layer networkbefore auto configuration;

FIG. 13 is a schematic view of an auto-configuring multi-layer networkafter auto configuration;

FIG. 14 is a schematic view of how node 722 can be seen by node 702according to the network of FIG. 13;

FIG. 15 is a schematic view of how node 704 can be seen by node 720according to the network of FIG. 13;

FIG. 16 a schematic view of an example of the propagation of theheartbeat through different ComLayers of an auto-configuring multi-layernetwork via virtualizer nodes;

FIG. 17 is a schematic view of an example of the stopping of thepropagation of the heartbeat through different ComLayers of anauto-configuring multi-layer network via virtualizer nodes;

FIG. 18 is a schematic view of an example of the sharing of thevirtualizing burden between multiple nodes in an auto-configuringmulti-layer network;

FIG. 19 is a schematic view of an example of the creation of asymmetricnetwork boundaries in an auto-configuring multi-layer network;

FIG. 20 is a state diagram the passive node ID auto-assignation statemachine;

FIG. 21 is a schematic view of an example of a user triggered nodelocalization using the multi-layer locator packet functionality;

FIG. 22 is a schematic view of an example of a user triggered nodecollaboration using the multi-layer locator packet functionality;

FIG. 23 is a schematic view of an example of a user triggered nodecollaboration between a wireless protocol ComLayer and a wired protocolComLayer using the multi-layer locator packet functionality; and

FIG. 24 is a schematic view of an example of a pod triggered nodelocalization using the multi-layer locator packet functionality

DETAILED DESCRIPTION

Generally stated, the non-limitative illustrative embodiment of thepresent invention provides an auto-configuring multi-layer networkincluding different communication protocols, namely both wired andwireless protocols, interchangeably and indifferently to interconnectvarious devices such as, for example, controllers, actuators, alarms,sensors, interfaces, etc.

In the forgoing description, for clarity and conciseness purposes,reference will be made to a list of terms which will now be defined.

-   Node: is meant to encompass any device participating in network    activities such as a controller, actuator, alarm, sensor, interface,    etc.-   ComLayer: the communication layer is meant to encompass any    communication link or sub-network (hardware/software), wired or    wireless, which provides the following functionalities:    -   a sender node can send data to all nodes on the network        (broadcasting);    -   a sender node of a data packet is known or can be known by the        receiver node;    -   each node is addressable;    -   any node can communicate with any node (point to point); and    -   any node can change ID on the network.

Examples of protocols that can be used are: CANbus/CANopen, ZigBee,TCP/IP, UDP/IP, etc.

-   ComLayerID: the communication layer ID is a layer node identifier    which is specific to a ComLayer, e.g. for CANbus/CANopen it is the 7    bits or 29 bits node identifier while for TCP/IP it is the IP    address of a node.-   Packet: is a group of data, which may contain sub-packets.-   Multi-layer: which involves a plurality of ComLayers.

Referring to FIG. 1, there is shown an example an autonomous wiredsub-network 20 within a wireless network 10. In such a setup,communication between the wired nodes 14 and 16 would be maintainedthrough the wired connection 22 even if wireless communication link 19is down, while nodes 11, 12 and 18 would loose communication.

The existence of a wired sub-network is essential in any situation wherecommunication between some of the nodes is critical, both for redundancyand performance reasons. Such critical situations are present for mostcontrol-loop, e.g. for nodes part of, for example, a valve controlsystem, an alarm control system, etc.

FIG. 2 show an example of a prior surveillance network 100, whichincludes a master/router 101 accessing a gas sensor 102, a shutoff valve104 and an alarm 106, all interconnected via communication link 109. Inthe shown example, if the gas sensor 102 detects an anomaly, itcommunicates with the master/router 101, which will then activate (orregulate) the shutoff valve 104 and activate the alarm 106. Since thisfunctionality is viewed as “safety-critical” in a surveillance networksuch as surveillance network 100, the communication link 109 is entirelywired.

Referring now to FIG. 3, if, for practical reasons, a wireless accessfrom the master/router 101 to the gas sensor 102 is desired, such asillustrated by wireless communication link 103, a wired communicationlink 109′ between the gas sensor 102, the valve 104 and the alarm 106 isstill required in order to ensure safe and reliable reaction of thesurveillance system 100′. To achieve this, a second master/router 107,which will be responsible for managing wired alarms, must be implementedas the master/router 101 cannot access the valve 104 and the alarm 106across two different types of protocols, e.g. wireless and wired.

However, as shown in FIG. 4, with a surveillance system 100″, whichincludes an autonomous wired sub-network 120, it becomes possible todeploy the surveillance network 100″ wirelessly through expandedwireless communication link 103″ and have a wired sub-network 120 tosustain the “safety-critical” function between the gas sensor 102″, thevalve 104″ and the alarm 106″ through wired communication link 109″. Inorder to properly integrate the autonomous wired sub-network 120 and thewireless communication link 103″, each of the nodes (e.g. themaster/router 101″, the gas sensor 102″, the valve 104″ and the alarm106″) is an auto-configuring node having a node virtualization functionreferred to as a virtualizer node. The node virtualization function isthe ability of a node to communicate with any other node in theauto-configuring multi-layer network regardless of its communicationprotocol, i.e. mirrors a node observed on one ComLayer onto anotherComLayer where the node is not initially observed, and will be furtherdetailed below.

Thus, deployment of a network such as, for example, the surveillancenetwork 100″ of FIG. 4, is easier, cheaper and integrated, and fornon-critical operations, the network can still be accessed andcontrolled wirelessly with a single master/router.

Virtualization Function

The virtualization function emulates the nodes of a given ComLayer ontoanother ComLayer, for example wired protocol (e.g. CANbus/CANopen) nodesonto wireless protocol (e.g. Zigbee) nodes and vice versa. Thisfunctionality allows nodes to communicate with each other regardless oftheir protocol.

To illustrate the virtualization function, reference will be made toFIGS. 5 a, 5 b and 5 c, which show a network 110 comprising three nodes112, 114 and 116 with the virtualization function, which will bereferred to as virtualizer nodes. Under normal condition, illustrated inFIG. 5 a, nodes 112 and 114 communicate with each other using ComLayer1(wired) link 113 while nodes 114 and 116 communicate with each otherusing ComLayer2 (wireless) link 115.

Referring now to FIG. 5 b, node 112, having a ComLayer1 ID α, and node116, a ComLayer2 ID β, cannot communicate directly over the sameprotocol, e.g. either wired or wireless, for example CANbus/CANopen orZigBee. In order for node 112 to send information to node 116, node 112uses node 114 as an intermediary node to relay the information betweenthe two protocols. To achieve this, the virtualizer node 114, using thevirtualization function, communicates with the target node 116 as if itwas the originating node 112 by pretending to have a ComLayer2 ID N(a)corresponding to the ComLayer1 ID (α) of the originating node 112.

Conversely, with reference to FIG. 5 c, in order for node 116 to sendinformation back to node 112, node 116 uses virtualizer node 114 as anintermediary node to relay information between the two ComLayers. Toachieve this, the virtualizer node 114, using again the virtualizationfunction, communicates with the target node 112 as if it was theoriginating node 116 by pretending to have a ComLayer1 ID N(β)corresponding to the ComLayer2 ID (β) of the originating node 116.

It is to be understood that the virtualization function can be appliedto multiple nodes simultaneously.

Virtualization make it so that each virtualizer node having a wiredprotocol ComLayer acts as a wireless protocol bridge between local wiredprotocol ComLayers (sometime comprising of a single node, since anun-wired node will detect only itself in its wired protocol ComLayer)thus, in effect, enabling both redundancy and bridging between wiredprotocol and wireless protocol ComLayers (for example betweenCANbus/CANopen and ZigBee).

For example, referring to FIG. 6, there is shown an auto-configuringmulti-layer network 150 comprising virtualizer nodes 132, 134, 136, 142,144 and 146. A first wired protocol link, ComLayer1 link 131,interconnects nodes 132, 134 and 136 while a second wired protocol link,ComLayer2 link 141, interconnects nodes 142 and 144. All of the nodes132, 134, 136, 142, 144 and 146 are further interconnected via wirelessprotocol ComLayer2 link 151. Each of the virtualizer nodes 132, 134,136, 142, 144 and 146 acts as a bridge, enabling communication from anywired protocol ComLayer1 or ComLayer2 links 131, 141 connected to itwith wireless protocol ComLayer3 link 151.

Thus, whenever one of the wired protocol links 131 (ComLayer1), 141(ComLayer2), or wireless protocol link 151 (ComLayer3), is down, a node132, 134, 136, 142, 144 or 146 may use the other available links 131,141 or 151. Whenever there are more than one available link 131, 141 or151, a node 132, 134, 136, 142, 144 or 146 may select which link 131,141 or 151 to use according to a given priority, for example givingpriority to a wired protocol link 131 (ComLayer1), 141 (ComLayer2) overa wireless protocol link 151 (ComLayer3) or the fastest available link.

However, each virtualizer node is more than a simple bridge. Beyond themanagement of both wireless (less frequent, bigger packets) and wired(more frequent, smaller packets) communications, it also acts as abuffer between wired/wireless communications and actively manages the“virtualization” and transmission load between nodes.

Thus, each virtualizer node acts as both a wired protocol node, forexample a CANbus/CANopen node, and a wireless protocol node, for examplea Zigbee node (coordinator, router, end-device).

Referring now to FIG. 7, there is shown the hierarchical structure 200of the components of the auto-configuring multi-layer network, which arethe node information packet 210, comprising the Unique ID (UID) 202,Functional ID (FNID) 204, Multi-Layer Link Q (MLQ) 206 and Multi-LayerTime To Live (MTTL) 208, the heartbeat packet 212, passive node IDauto-assignation 214, the virtualizer 216 and the locator packet 218,all of which will now be further detailed.

Unique ID (UID)

The UID 202 is a string or a number assigned to a device (node), whichserves as a universally unique ID. Examples of such an ID scheme aredefined by ISO/IEC 8802-3 and IEEE MAC EUI-64. Any scheme can be used aslong as all the nodes in a same network use the same scheme.

Functional ID (FNID)

The FNID 204 defines the current mode of operation of a device (node)and includes two fields:

-   an application field that defines an application in which a device    currently operates; and-   a function field that defines the function that the device currently    fulfills within the current application.

For example:

-   application field value: Room Temperature Control; and-   function field: Temperature Sensor 1.

The FNID 204 may be assigned, for example, 16 bits of which theapplication field occupied 8 bits and the function field the remaining 8bits.

Within a broadcasting method such as the multi-layer heartbeat scheme,which will be defined further on, the FNID 204 allows passive functionalmapping of a network, in turn allowing functional collaboration of nodeswithout the use of a slow active mapping process.

A number of manufacturer defined functions will exist for a specificmanufacturer defined application. Therefore, nodes with cooperationcapabilities should be configured to know the applications in which theywill operate, which functions it can occupy and with which functions itcan cooperate.

TABLE 1 Room Control application functional mapping example ApplicationName Application ID Room Control 01 Function Name Function IDTemperature Sensor 1 10 Temperature Sensor 2 11 Temperature Sensor 3 12Temperature Sensor 4 13 Heater Controller 1 20 Heater Controller 2 21Collaboration map Heater Controller 1 <-> Temperature Sensor 1 HeaterController 1 <-> Temperature Sensor 2 Heater Controller 2 <->Temperature Sensor 3 Heater Controller 2 <-> Temperature Sensor 4 FNIDtimeout = 1 s

Table 1 shows and example of the functional mapping for the room controlapplication with its possible functions and possible collaborationbetween the various functions.

Multi-layer Link Quality (MLQ)

The MQL 206 is a value which allows the evaluation of the interactionperformance a node can get from another node. Its value is a function ofthe following characteristics:

-   node dynamic response time: relative to its current load;-   node fixed or static response time: determined by the node default    or user configuration; and-   link speed: initially set by the node itself according to the    slowest of the listed items, the value of which can be seen as an    overall node response time and can be represented by a log scale.

TABLE 2 MLQ typical log scale 1: 1 nS 2: 10 nS 3: 100 nS 4: 1 μS 5: 10μS 6: 100 μS 7: 1 mS 8: 10 mS 9: 100 mS 10: 1 S 11: 10 S 12: 100 S

Table 2 shows an example of a MLQ 206 using 4 bits to represent a logscale.

Within a broadcasting method such as the multi-layer heartbeat scheme,which will be defined further on, the MQL 206 allows any receiving nodeto passively and continuously know which kind of communicationperformance it can get from a specific node.

When virtualizing a node, a virtualizer node can choose to increase theMQL 206 in order to take into account degradation related to thevirtualizing process or link switch and thus allow a good estimation ofnode interaction performance. For example, a node depending on acritical collaboration with a broadcasting node could choose to enter afail-safe mode if it detects that the interaction performance decreasesunder a required level.

Multi-Layer Time To Live (MTTL)

The MTTL 208 is a counter with an initial value specific to eachindividual node which can be set by the manufacturer or through anauto-configuration process when the node is connected to the network.

Within a broadcasting method such as the multi-layer heartbeat scheme,which will be defined further on, the MTTL 208 allows a virtualizer nodeto decide whether or not a node will be virtualized on a furtherComLayer. Each time a virtualizing process of a node occurs, its MTTL208 counter is decreased. When it reaches 0, the node will not bevirtualized any further. A constant value must be reserved in order toallow infinite virtualization.

The MTTL 208 may be implemented using, for example, 4 bits with thevalue 15 reserved for infinite virtualization, leaving 14 possiblevirtualization stages.

Node Information Packet

The node information packet 210 is a data packet containing at least thefour fields, which are: the UID 202, the FNID 204, the MLQ 206 and theMTTL 208 fields. The synergy of the joint information contained in thosefields forms the basis of the auto-configuring multi-layer networkthrough the multi-layer heartbeat broadcasting scheme or any otherbroadcasting scheme.

Possible functional collaboration between two nodes, identified by theirUID 202, is established by their FNID 204 and can be decided upon fromtheir MLQ 206 and MTTL 208, all of which are broadcasted in theirrespective node information packet 210.

The node information packet 210 must be broadcasted in a formatrecognizable by virtualizer nodes since any of its fields may bemodified by a virtualizer node in the communication process.

Multi-Layer Heartbeat Packet

The multi-layer heartbeat packet 212, from hereon end referred to as theheartbeat 212, is a packet sent at defined intervals by all nodes andpropagated through the various ComLayers by the virtualizer nodes. Sincethe heartbeat 212 may propagate over different types of communicationlayers (i.e. protocols), its content is not defined in a fixed manner.The heartbeat 212 should, however, contain the following items in orderto sustain the auto-configuring multi-layer network functionalities:

-   -   an indicator that this packet is an auto-configuring multi-layer        network heartbeat 212;    -   the source node ComLayer ID, which is required in order to allow        mirroring by virtualizer nodes and for building local node        registries; and    -   a node information packet; and    -   optionally, a heartbeat interval.

The heartbeat 212 packet may contain additional information in order toperform optimization of current ComLayer use.

The presence of a node heartbeat 212 on a given ComLayer indicates thatthe node is alive on that specific ComLayer. Conversely, the absence ofa node heartbeat 212 on a given ComLayer indicates that the node is deadon that specific ComLayer. Accordingly, a device (node) is consideredalive upon the reception of a heartbeat 212 from that device and isconsidered dead if no heartbeat 212 is received from that device withina fixed period or, if used, the device heartbeat interval.

In the auto-configuring multi-layer network, all nodes send a heartbeat212 packet at respective defined intervals that are not necessarily thesame for every node but are static in time.

Since all nodes on the auto-configuring multi-layer network receive thenode information packet 210 via the heartbeat 212, each node is capableof passively building a node map and a functional map of the network.Functional mapping then allows a node to trigger functionalcollaboration. If a node involved in a collaboration discovers by thetimeout of the heartbeat 212 that the collaborative node has died, itmay search its functional map for other nodes capable of occupying thesame functionality and thus start a new redundant collaboration.

It is the task of the virtualizer nodes to handle conversion of theheartbeat 212 and it transmission from a ComLayer format to anotherComLayer format.

Upon reception of a heartbeat 212, which contains the node informationpacket 210, a node is in position to decide whether or not it willcontinue to collaborate or trigger a collaboration with another node,which choice is based on the MLQ 206 and/or MTTL 208.

With this scheme, any receiving node can decide to occupy a FNID 204which has been left free.

The heartbeat 212 pace can be fixed through its heartbeat intervalaccording to functional and network response time requirements. Thefaster this pace, the faster the redundancy will trigger. However,faster pace also means more data transfer which might contribute inComLayer link performance degradation. It should be noted that thecombination of a statically defined heartbeat interval, with staticallydefined MLQ 206 and MTTL 208, results in functional and network mappingprocesses occurring in a deterministic manner.

Each node may build a map of the auto-configuring multi-layer network bysimply maintaining a registry of entries containing the followinginformation, for each node from which it receives a heartbeat 212:

-   node UID 202;-   node ComLayerID;-   node device heartbeat interval (optional);-   last MLQ 206 (optional); and-   last MTTL 208 (optional).

A node entry is added or updated every time a heartbeat 212 is received.A node entry is remove if no heartbeat 212 is receive within a fixedperiod or, optionally, within the node device heartbeat interval.

The node building the registry is then able to locate and instantiatecommunication with any recorded node using its UID 202 or ComLayerID.

A pseudo-geographic view may also be created, assuming that the MLQ 206can be represented as a distance.

The functional mapping is performed similarly to the network mappingexcept that the FNID 204 is added to the registry maintained by the nodebuilding the functional map. The maintaining node is then able toinstantiate collaboration with nodes capable of fulfilling the requiredfunction, as indicated by their FNID 204.

Referring to FIG. 8, there is shown an example of the functional statesof nodes in an auto-configuring multi-layer network at boot up. Eachnode contains a set of user configured or manufacturer fixed rules whichdefine which FNID (function) a node can occupy within the network. Inthe illustrated example, Node 1 can occupy the END (function) of“Temperature sensor 1 or 2” within the application “Room Control”.

FIG. 9 shows a FNID selection state machine 800. The states andconditions/transitions of the state machine 400 are indicated by blocks302 to 316.

The state machine 800 is initiated at block 302 when a node is booted upwhere it starts a timeout counter. The node then enters, at block 304,the “SEARCH_FNID” state and selects a free FNID from amongst itspossible FNIDs and enters a waiting period.

At block 306, if no other node sends a heartbeat 212 (see FIG. 7)containing the selected FNID within the timeout period, then the nodeenters, at block 308, the “OCCUPY_FNID” state and starts accomplishingthe behavior associated with the FNID function.

Then, at block 310, if a conflicting heartbeat 212 is received (i.e.with the same FNID), the node enters, at block 312, the “FREE_FNID”state where the FNID is freed. Following which, at block 314, the noderesets its timeout counter and proceeds back to the “SEARCH_FNID” stateat block 402.

If, at block 316, if a conflicting heartbeat 212 is received within thetimeout period, then the node enters the “FREE_FNID” state where theFNID is freed. Following which, once more at block 314, the node resetsits timeout counter and proceeds back to the “SEARCH_FNID” state atblock 402.

Boot Up Sequence Example

Referring back to FIG. 8, there will be illustrated an example of theFNID selection during the boot up sequence.

We will assume that Node 2 is the first node to be powered on, it firstsends a heartbeat containing an empty FNID field to indicate that itdoes not occupy any specific function at the moment. Node 2 then selectsa free FNID amongst its list of possible FNIDs, i.e. “RoomControl/Temperature Sensor 1” or “Room Control/Temperature Sensor 2”.Assuming “Room Control/Temperature Sensor 1” is selected, then Node 2enters a wait period. If no other node sends a heartbeat containing thisFNID within the timeout period, Node 2 starts occupying the selectedFNID and accomplishes it behavior.

Nodes 1, 3, 4, 5, 6, 7 then boot up and send their respective heartbeatswith an empty FNID filed.

Since Node 2 does not receive any conflicting heartbeats, it starts tooccupy and accomplish the “Room Control/Temperature Sensor 1”functionality. A heartbeat with the FNID field set to “RoomControl/Temperature Sensor 1” is then sent.

Node 1 receives a heartbeat from Node 2 indicating that it now occupiesthe “Room Control/Temperature Sensor 1” FNID. Node 1 then selects thenext free FNID from its list of possible FNIDs, which is “RoomControl/Temperature Sensor 2” FNID. Nodes 3, 4 and 7 occupy functionwhich are no conflicting with Nodes 1 and 2.

Since Node 1 does not receive any conflicting FNID, it starts to occupyand accomplish “Room Control/Temperature Sensor 2 functionality. Aheartbeat with the FNID field set to “Room Control/Temperature Sensor 2”is then sent.

Node 5 comes with a fixed FNID which is “Room Control/TemperatureController 1”.

From its collaboration rule set, it knows it can interact with nodesacting as FNIDs “Room Control/Temperature Sensor 1 or 2”. Performingnetwork functional mapping using its node registry, it knows that Nodes1 or 2 can be used in its collaboration. Since Node 2 occupies “RoomControl/Temperature Sensor 1” FNID, Node 5 establishes collaborationwith Node 2. Node 1 is kept as a backup which could be used as aredundant sensor. In case Node 2 dies, i.e. absence of a heartbeat.

Node 6 starts collaboration with Node 3. Other nodes behave as standalone sensors and can be accessed by any monitoring node.

Virtualizer Node

The virtualizing function is accomplished by a virtualizer 214 node (seeFIG. 7), which node has access to at least two ComLayers. It mirrors anode observed on a given ComLayer onto another ComLayer where the nodeis not observed. On the virtualizing side, the node behaves like anyother node. The only difference is that the MLQ 206 field of the nodeinformation packet 210 broadcasted in the heartbeat 212 may be increasedby the virtualizer node 214 in order to take into account theperformance degradation due to the virtualizing process (i.e.communication layer switch and mirroring). The MTTL 208 is also decreaseby one every time it goes through a virtualizer 214 node until itreaches 0 in order to limit the number of virtualizer 214 nodes acommunication will go through. This scheme allows communication betweentwo nodes transparently over MTTL 208 number of successive ComLayers.

The virtualizing process occurs when a virtualizer 214 node sees a nodeon one ComLayer but not on any other one to which it has access.Observation is made through the heartbeat network mapping scheme. Anynode can be a virtualizer 214 node. Any virtualizer 214 node can alsodecide the maximum number of nodes it will virtualize in function of itprocessing capabilities. This maximum could be preset or/and dynamicallychanged in function of the node's available processing power. Thismaximum could be set for each ComLayer available and/or as a totalnumber of virtualized nodes. This allows the implementation ofvirtualizer 214 nodes on low processing power devices.

All virtualizer 214 node have the role of restoring a communication linkbetween other nodes. Accordingly, a communication link may be backed bya plurality of nodes without requiring any configuration.

Placing many virtualizer 214 node between the same two communicationlinks also has interesting effects. Each virtualizer 214 node added willin fact strengthen the bridge between the two ComLayers, strenghten theredundancy and increase the throughput speed levels by handling a partof the traffic.

A virtualizer 214 node will not virtualize a node whose MTTL 206 hasreached 0, allowing creation of virtual network boundaries, which willbe further detailed below. However, as previously mentioned, a specialMTTL 206 constant exists so as to allow infinite virtualisation of anode.

The virtualizing process may be seen as some sort of “passive meshing”behavior since it is not performing any search for a routing path.

Virtualizer Node Assignation State Machine

FIG. 10 shows a virtualizer 214 node assignation state machine 500. Thestates and conditions/transitions of the state machine 500 are indicatedby blocks A to G and 502 to 522, respectively.

The state machine 500 is initiated whenever there is a change in thecommunication links (or when the auto-configuring multi-layer network isinitiated). The state machine 500 starts at block 502 by selecting thefirst node entry (entry 0), first communication link (link 0) in itsnode registry and enters state A.

At block 504, if the last node entry of the node registry has beenselected, then the state machine 500 proceeds to state G where itterminates.

At block 506, if the selected node entry of the node registry has notbeen selected, then the state machine 500 proceeds to state B.

The state machine 500 then verifies, at block 508, if the selectedcommunication link is the last communication link entry for the selectednode entry. If so, the next node entry, first communication link, isselected and the state machine 500 proceeds back to state A. If theselected communication link is not the last communication link entry ofthe selected node entry, then, at block 510, the state machine 500proceeds to state C.

If, at block 512, the node listed in the selected communication linkentry has been virtualized, the state machine 500 proceeds to state D,if not, at block 514, the state machine 500 proceeds to state F.

In state D, the state machine 500 verifies if the node listed in theselected communication link entry is detected (e.g. its node informationpacket 210 is detected), if not, at block 516, it proceeds to state E,if so, at block 518, it sets the node as not being virtualized (it isnow detected) and proceeds to state E.

In state F, at block 520, the state machine 500 verifies if the nodelisted in the selected communication link entry is detected (e.g. itsnode information packet 210 is detected), if not, at block 520, it setsthe node as being virtualized, executes a virtual ID auto-assignationstate machine similar to the node ID auto-assignation state machine thatwill be detailed further below and proceeds to state E, if so, at block522, it proceeds to state E

Node Registry Update State Machine

FIG. 11 shows a node registry update state machine 600 that is executedwhen a new node information packet 210 is received. The states andconditions/transitions of the state machine 600 is indicated by blocks602 to 604.

The state machine 600 starts in state 602 with an initial node registry(which may be empty at startup) and, at block 604, verifies if a nodeinformation packet 210 is received, if so the state machine uses theinformation from the node information packet 210 to create a new entryin the node registry if the UID 202 of the node information packet 210is not registered in the node registry or updates the fields of thecorresponding entry if the UID202 of the node information packet 210 isalready registered in the node registry.

Furthermore, an entry in the node registry may be removed if acorresponding node information packet 210 (e.g. with the same UID 202)is not received within a given period of time.

It is to be understood that not all of the nodes of an auto-configuringmulti-layer network may have the processing capability required to be avirtualizer 214 node.

Auto-Configuration Example

Referring to FIG. 12, there is shown an example of an auto-configuringmulti-layer network 700 comprising:

-   an access point node 702;-   nodes with low processing capabilities, which could not be assigned    specific functions, 704, 708, 710, 714, 716, 720, 722, 724; and-   nodes with the virtualization function capability 706, 712, 718,    726.

At startup, the auto-configuring multi-layer network 700 also comprises:

-   five wired protocol ComLayers 701, 703, 705, 709, 711; and-   four wireless protocol ComLayers 707, 715, 717, 719.

In FIG. 12, the nodes having the the virtualization function capabilityare identified with a “v” (i,e. virtualizer nodes).

Auto Configuration Sequence

At startup, the devices (e.g. nodes 702, 704, 706, 708, 710, 712, 714,716, 718, 720, 722, 724, 726) are powered ON asynchronously. The nodes702, 704, 706, 708, 710, 712, 714, 716, 718, 720, 722, 724, 726 usingselect a local address, which is done using a node ID assignation statemachine which will be detailed further below.

The devices start building their respective node registries byexchanging node information packet 210 using respective heartbeats.

On the wired protocol Comlayers 701, 703, 705, 709, 711, the heartbeatsare sent by each node, for example, every second. This allows any nodeto discover any other node on the wired protocol Comlayer at any time.When a node discovers another node, it adds the discovered node'sinformation to its node registry. In the same way, a node can be removedfrom the node registry when it disappears from the network, i.e. itsnode information packet 210 is not received anymore.

As for the wireless protocol ComLayers 707, 715, 717, 719, heartbeatsare broadcasted at device boot up and then at a slower interval in ordernot to saturate the wireless protocol Comlayers 707, 715, 717, 719, forexample at every 10 seconds or slower.

This can be similarly performed on any type of Comlayer as long as nodeinformation packets 210 are exchanged between every node connected on itat a rate that allows network functionality to be fulfilled.

The nodes with the virtualization function capability 706, 712, 718, 726will start to analyze their node registry to figure out which nodesrequire virtualization.

TABLE 3 Sample node registry before virtualization ComLayer1 IDComLayer2 ID ComLayer3 ID UID (wired) (wired) ID (wireless) MLQ FNID0x0100402000 03 Not present 0x23325523 100 Valve Controller 0x010040240204 03 Not present 120 Humidity Sensor 0x0100402154 Not present 200x53325746 900 Simple Virtualizer

TABLE 4 Sample node registry after virtualization ComLayer1 ID ComLayer2ID ComLayer3 ID UID (wired) (wired) (wireless) MLQ FNID 0x0100402000 0354 0x23325523 100 Valve (virtualized) Controller 0x0100402402 04 030x83325349 120 Humidity (virtualized) Sensor 0x0100402154 Not enough 200x53325746 900 Simple processing Virtualizer available (not virtualized)

Table 3 and Table 4 show an example of a node registry before and aftervirtualization. It may be observed that the devices (nodes) 0x0100402000and 0x0100402402 are virtualized on wired protocol ComLayer2 andwireless protocol ComLayer3, respectively. However the currentvirtualizer node determined that it did not have enough processing powerto virtualize a third device, leaving it for another virtualizer node.This allows the virtualizer node to never reach overload, thus helpingnetwork stability.

Communication Path Examples Case 1:

Referring to FIG. 13, node 702 wants to communicate with node 704. Node702 looks for node 704's UID in its node registry and locates node 704on wireless protocol ComLayer 707 and on wired protocol ComLayer 701. Onthe wireless protocol ComLayer 707 nodes 702 and 704 are virtualized bynode 706 and on wired protocol ComLayer 701, node 704 is alsovirtualized by node 706 which means node 702 decides if it uses wirelessprotocol ComLayer 707 or wired protocol ComLayer 701 to reach the node704. If it selects wired protocol ComLayer 701, the communication willaddress as if on a wired communication link but will be transmitted bywire to node 706 and then wirelessly from node 706 to node 704. The MLQfield can then be used to select the optimal link.

Case 2:

Node 702 wants to communicate with node 722, which is some sort of worstcase scenario. FIG. 14 illustrates how node 722 can be seen by node 702.

Case 3:

Node 720 wants to communicate with node 704. FIG. 15 illustrates hownode 704 can be seen by node 720. It may be observed that there is aredundant link between node 720 and 718. The MLQ field can then be usedto select the optimal link.

Heartbeat Propagation by Virtualizer Nodes

Referring to FIG. 16, there is shown an example of the propagation ofthe heartbeat through different ComLayers of an auto-configuringmulti-layer network via virtualizer nodes.

Node 1 sends a heartbeat on ComLayer1 with a MLQ of, for example, 100ms, which is the response time of a sensor associated with Node 1.Virtualizer Node 2 receives the heartbeat from Node 1 on ComLayer1,virtualizes Node 1, add 20 ms to the MLQ in order to take into accountvirtualization delay. It then sends the virtualized heartbeat of Node 1on ComLayer 2 with a MLQ of 120 ms.

Virtualizer Node 3 receives the virtualized heartbeat of Node 1.Similarly, 50 ms is added to the MLQ in order to take into account thecurrent load of virtualizer Node 3. Virtualizer Node 3 then sends thevirtualized heartbeat of Node 1 on ComLayer3 with a MLQ of 170 ms. Node4 receives the heartbeat from virtualized Node 1 on ComLayer3. Node 4can then decide whether or not it will interact with Node 1 based on itsMLQ or other condition.

The collaboration criteria could be, for example:

-   if MLQ<100 ms: use as primary sensor in a close loop collaboration;-   if 100 ms<MLQ<500 ms: use node only as a backup sensor in a close    loop collaboration; and-   if 500 ms<MLQ: do not use node.

Virtualization Boundary

Referring to FIG. 17, there is shown an example how the propagation ofthe heartbeat through different ComLayers of an auto-configuringmulti-layer network via virtualizer nodes is stopped.

Node 1 sends a heartbeat with a MTTL set to 2. Virtualizer Node 2receives the heartbeat of Node 1 and, since the MTTL is greater than 0,virtualizes Node 1 on ComLayer2. The MTTL of virtualized Node 1 isdecreased to 1 and then sent on ComLayer2.

Virtualizer Node 3 receives the heartbeat of virtualized Node 1 and,since the MTTL is greater than 0, virtualizes Node 1 on ComLayer3. TheMTTL of virtualized Node 1 is decreased to 0 and then sent on ComLayer3.

Virtualizer Node 4 receives the heartbeat of virtualized Node 1 and,since the MTTL is 0, does not virtualize Node 1 on ComLayer4.

Traffic Load Diffusion

Referring to FIG. 18, there is shown an example how the virtualizingburden can be shared between multiple nodes in an auto-configuringmulti-layer network.

Assuming Nodes 4, 5 and 6 each have a three-node virtualizing capacity,this means that a total virtualization of nine nodes can occur on theauto-configuring multi-layer network.

The auto-configuring multi-layer network is configured in the followingmanner at boot up:

-   virtualizer Node 4 virtualizes Node 1 on ComLayer2;-   virtualizer Node 5 virtualizes Node 2 on ComLayer2;-   virtualizer Node 6 virtualizes Node 3 on ComLayer 2; and-   virtualizer Node 6 virtualizse Node 7 on ComLayer1.

If virtualizer Node 4 cannot virtualize nodes anymore, virtualizer Nodes5 or 6 can take over the virtualization process for Node 1 according totheir current capacity. Accordingly, the auto-configuring multi-layernetwork may be reconfigured in the following manner:

-   virtualizer Node 5 virtualizes Node 1 on ComLayer2;-   virtualizer Node 5 virtualizes Node 2 on ComLayer2;-   virtualizer Node 6 virtualizes Node 3 on ComLayer2; and-   virtualizer Node 6 virtualizes Node 7 on ComLayer1.

Network Asymmetric Virtual Boundaries

Referring to FIG. 19, there is shown an example how asymmetric networkboundaries can be created in an auto-configuring multi-layer network inorder to provide performance and security control.

The auto-configuring multi-layer network is configured such that nodesare assigned the following initial MTTL:

-   Nodes 1 and 2: MTTL=1;-   virtualizer Node 3: MTTL=0;-   Node 6: MTTL>=2; and-   virtualizer Nodes 4 and 5: arbitrary values.

Nodes 1 and 2 are virtualized on ComLayer2 and ComLayer3 by virtualizerNode 4 and, since their respective MTTL is decreased to 0 by virtualizerNode 4, Nodes 1 and 2 are not virtualized further by virtualizer Node 5.As for virtualizer Node 3, it is not virtualized by virtualizer Node 4since its MTTL is already 0. Node 6 is virtualized on ComLayer3 byvirtualizer Node 5 and virtualized by virtualizer Node 4 on ComLayer1and ComLayer2.

The end result is that Node 6 can be accessed by Nodes 1 and 2 but Node6 cannot access Nodes 1 and 2. Thus, each node possesses its own virtualboundary which is defined by its initial MTTL, which can be fixed by theuser. This behavior can be used to create sub-networks, allowingperformance increases and/or to instantiate security policies.

Passive Node ID Auto-Assignation

Referring back to FIG. 7, the passive node ID auto-assignation 216depends on the heartbeat packet 212. However, it could be used with anyscheme that does not necessarily contain the node information packet210. The passive node ID auto-assignation 216 simply requires a packetcontaining the source ComLayer ID to be broadcasted on a network branchat a defined interval.

Although the passive node ID auto-assignation 216 is designed for use onan auto-configuring multi-layer network, it can also be implemented onany network layer which presents the ComLayer characteristics and doesnot have a concurrent protocol-specific address self-assignation scheme

The passive node ID auto-assignation 216 allows a node to passivelydetect free ComLayerIDs in order to self-assign one as its own. Thisallows nodes with address self-assignation and nodes with fixedaddresses to be used on the same network.

Used within the auto-configuring multi-layer network, the passive nodeID auto-assignation 216 has the advantage of requiring no additionaldata to be sent over the network, the heartbeat packet 212 containingall of the required information.

Passive Node ID Auto-Assignation State Machine

FIG. 20 shows a passive node ID auto-assignation state machine 800. Thestates and conditions/transitions of the state machine 800 are indicatedby blocks 802 to 814.

The state machine 800 is initiated at block 802 when a node has itsComLayerID cleared (or does not have a ComLayerID, such as when thenetwork is initiated). It then enters, at block 804, the“NODE_ID_SEARCH” state where the node selects a ComLayerID from unusedComLayerID present in the registry maintained by the node. In thatstate, the node is not authorized to send anything else then heartbeatsto the rest of the network.

At block 806, the node initiates its heartbeat timer at the end of whichit enters, at block 808, the “NODE_ID_STABLE” state where the node cancommunicate through the network. At block 810, the node again initiatesits heartbeat timer at the end of which it sends a heartbeat with itsComLayerID. Then, at block 812, if a ComLayerID collision occurs, i.e. aheartbeat with the same ComLayerID is received, the node clears itsComLayerID and proceeds back to the “NODE_ID_SEARCH” state at block 904.

While in the “NODE_ID_SEARCH” state, at block 814, the node continues tomonitor for ComLayerID collisions in which case it clears its ComLayerIDand selects a new one.

It is to be understood that depending on when each node starts its timeror which node sends it's heartbeat first for nodes having the samepriority time, this may affect the final configuration of theauto-configuring multi-layer network.

Multi-Layer Locator Packet

Referring back to FIG. 7, the multi-layer locator packet 218 is a packetsent by a node when a collaboration is triggered by a user. It allowsnodes to recognize each other and then trigger a collaboration behaviorover the auto-configuring multi-layer network.

The multi-layer locator packet 218 contains the following:

-   an indicator that this packet is a locator packet; and-   a node information packet 210.

A user can trigger a node, for example by pressing a button on a deviceassociated with the node, to start broadcasting a locator packet 218 ata regular interval for a predetermined period. Any node needing nodelocalization can catch the locator packet 218 and begin its interactionwith the node.

The broadcasting, or yelling, of a locator packet 218 can be of twodifferent types: localization yelling and collaboration yelling.Localization yelling is triggered by a localization request and has anassociated localization yelling period while collaboration yelling istriggered upon a successful collaboration assignation and has anassociate collaboration yelling period.

Node Localization Triggering

Referring to FIG. 21, there is shown an example of a user triggered nodelocalization using the multi-layer locator packet 218 (see FIG. 7)functionality.

A user 5 triggers 902 the locator packet broadcast on Node 1, forexample by shortly pressing a multi-use button on the device associatedwith Node 1. Pressing shortly the multi-use button a second time may beused, for example, to stop the broadcast.

Node 1 then starts localization yelling 904 and a pod 900 receives 906the locator packet allowing Node 1 localization and configurationretrieval. Node 1 then stops localization yelling 904 after thelocalization yelling period expires.

Node Collaboration Triggering

Referring to FIG. 22, there is shown an example of a user triggered nodecollaboration using the multi-layer locator packet 218 (see FIG. 7)functionality.

A user 5 triggers 902 the locator packet broadcast on Node 1, forexample by shortly pressing a multi-use button on the device associatedwith Node 1. Pressing shortly the multi-use button a second time may beused, for example, to stop the broadcast.

Node 1 then starts localization yelling 904 until the localizationyelling period expires.

The user 5 then triggers 908 the locator packet on Node 3 within thelocalization yelling period of Node 1. Since Node 3 is currentlyreceiving 910 the locator packet from Node 1, collaboration is initiatedbetween Node 1 and Node 3 on the basis of their respective FNIDs. BothNode 1 and Node 3 keep localization yelling as long as collaboration isnot successful. If collaboration fails, Node 1 and Node 3 simply stopyelling after the expiration of their respective localization period.

Upon the establishment of a successful collaboration between Node 1 andNode 3, both nodes start collaboration yelling until the collaborationyelling period expires to indicate that collaboration was establishedsuccessfully.

ComLayer Setting Exchange within Collaboration Establishment

Referring to FIG. 23, there is shown an example of a user triggered nodecollaboration between a wireless protocol ComLayer and a wired protocolComLayer using the multi-layer locator packet 218 (see FIG. 7)functionality, namely the exchange of ZigBee network parameter (wirelessComLayer1) over a wired link (wired ComLayer2). This allows a wirelessnetwork configuration and security information to be exchanged over awired secure link

In the illustrated example, the following will be assumed:

-   Node 1 support a ZigBee wireless protocol ComLayer (ComLayer1) and    possess a full ZigBee configuration set, i.e. PanID, Security Key,    etc.; and-   Nodes 2 and 3 support a Zig Bee wireless protocol ComLayer    (ComLayer1) but have all ZigBee parameters set to default, i.e.    different then the ZigBee configuration of Node 1.

A user 5 triggers 902 the locator packet broadcast on Node 1, forexample by shortly pressing a multi-use button on the device associatedwith Node 1. Pressing shortly the multi-use button a second time may beused, for example, to stop the broadcast.

The user 5 then triggers 912 the locator packet broadcast on Nodes 2 and3 within the localization period of Node 1 by shortly pressing Multi-usebutton. Since Nodes 2 and 3 are currently receiving the locator packetfrom Node 1, collaboration is initiated between Nodes 1, 2 and 3 on thebasis of their respective FNIDs. Nodes 2 and 3 keep localization yellingas long as collaboration is not successful. If collaboration fails, Node1 and Node 3 simply stop yelling after the expiration of theirrespective localization period.

Collaboration information is exchanged over the wired protocol ComLayer2(for example the CANbus protocol) between Nodes 1, 2 and 3. Node 1 takethe position of the ZigBee (i.e. wireless protocol ComLayer1) parameterserver since it was the first node to be triggered. Nodes 2 and 3 detectthis condition and retrieve their new parameters over wired protocolComLayer2. At the end of the process, Nodes 1, 2 and 3 possess the sameZigBee network configuration.

Upon the establishment of a successful collaboration between Nodes 1, 2and 3, all nodes start collaboration yelling until the collaborationyelling period expires to indicate that collaboration was establishedsuccessfully.

Pod Triggered Node Localization

Referring to FIG. 24, there is shown an example of a pod triggered nodelocalization using the multi-layer locator packet 218 (see FIG. 7)functionality.

A pod 900 first builds a network map from available ComLayer information914. A user 5 then uses 916 the pod 900 to send 918 a localizationyelling command to Node 2 which, when it receives 920 the localizationyelling command, starts localization yelling and thus broadcast itslocator packet.

The user 5 is then able to visually locate Node 2 and make it stop 922localization yelling by shortly pressing a multi-use button on thedevice associated with Node 2.

The localization packet presence or absence can then be used for networkfault localization or debugging purposes.

Although the present invention has been described by way of particularembodiments and examples thereof, it should be noted that it will beapparent to persons skilled in the art that modifications may be appliedto the present particular embodiment without departing from the scope ofthe present invention.

1. A method for auto-configuring a multi-layer network including atleast two layers using different communication protocols tointerchangeably interconnect at least two nodes, the method comprising:providing each node with an information packet including: a uniqueidentifier; a function identifier; a link quality; and a time to livecounter; for each node, broadcasting at defined intervals a heartbeatpacket including: an indicator that the packet is a heartbeat packet; alayer node identifier specific identifying the broadcasting node withina given layer; and the information packet of the broadcasting node;identifying nodes connected to at least a first layer and a second layerof the at least two layers as virtualizer nodes; for each virtualizernode: a) mirroring nodes observed by the virtualizer node on the firstlayer onto the second layer, including assigning each first layer node alayer node identifier on the second layer; and b) mirrors nodes observedby the virtualizer node on the second layer onto the first layer,including assigning each second layer node a layer node identifier onthe first layer; for each node, building a registry comprising an entryfor each node from which a heartbeat is received, the registry entryincluding: the unique identifier of the node from which a heartbeat isreceived; and the layer node identifiers of the node from which aheartbeat is received; for each node, removing from the registry theentry for each node from which a heartbeat packet has not been receivedwithin a fixed period; wherein a source node selects a layer tocommunicate with a destination node based on the source node registry.2. A method according to claim 1, wherein at least one layer uses awireless communication protocol and at least one layer uses a wiredcommunication protocol.
 3. A method according to claim 2, wherein: i)the mirroring of nodes observed on the first layer onto the second layerfurther includes converting the heartbeat of the nodes observed on thefirst layer into a format of the second layer; and ii) the mirroring ofnodes observed on the second layer onto the first layer further includesconverting the heartbeat of the nodes observed on the second layer intoa format of the first layer.
 4. A method according to claim 2, whereinthe mirroring of nodes observed on the first layer and second layerfurther includes decreasing the time to live counter of the mirrorednodes.
 5. A method according to claim 4, wherein the mirroring of nodesobserved on the first layer and second layer is effectuated only fornodes whose time to live counter is great than
 0. 6. A method accordingto claim 4, wherein each registry entry further includes the time tolive counter of the node from which a heartbeat is received.
 7. A methodaccording to claim 6, further comprising deciding for the source nodewhether to collaborate with the destination node based on the time tolive counter of the destination node.
 8. A method according to claim 2,wherein the functional identifier is composed of two fields: anapplication field that defines an application in which the nodecurrently operates; and a function field that defines a function thatthe node currently fulfills within the current application.
 9. A methodaccording to claim 8, wherein each registry entry further includes thefunctional identifier of the node from which a heartbeat is received.10. A method according to claim 9, further comprising deciding for thesource node whether to collaborate with the destination node based onthe functional identifier of the destination node.
 11. A methodaccording to claim 2, wherein each registry entry further includes thelink quality of the node from which a heartbeat is received.
 12. Amethod according to claim 11, wherein the mirroring of nodes observed onthe first layer and second layer further includes increasing the linkquality of the mirrored nodes.
 13. A method according to claim 12,further comprising deciding for the source node whether to collaboratewith the destination node based on the link quality of the destinationnode.
 14. A method according to claim 2, wherein the heartbeatbroadcasting interval, the link quality and the time to live counter areall statically defined, resulting in the auto-configuring a multi-layernetwork operating in a deterministic manner.
 15. A method according toclaim 2, further comprising: triggering the broadcasting of a locatorpacket of the source node to establish a collaboration with at least onedesired collaboration node, the source node locator packet including: anindicator that the packet is a locator packet; and the informationpacket of the source node; triggering the broadcasting of a locatorpacket of the at least one desired collaboration node within alocalization period associated with the source node, each desiredcollaboration node locator packet including: an indicator that thepacket is a locator packet; and the information packet of the desiredcollaboration node; initiating the collaboration between the source nodeand the at least one desired collaboration node on the basis of theirrespective functional identifiers; and broadcasting that thecollaboration between the source node and the at least one desiredcollaboration node was successfully initiated until a collaborationbroadcasting period expires.
 16. A method according to claim 2, whereinfurther comprising setting the time to live counter of each node so asto define virtual boundaries within the multi-layer network.